Date: Thu, 20 Oct 94 04:30:24 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: List Subject: Ham-Digital Digest V94 #346 To: Ham-Digital Ham-Digital Digest Thu, 20 Oct 94 Volume 94 : Issue 346 Today's Topics: ampr.org conventions? Does a TM 732 E/A can work at 9600 bauds ? FBB or MSYS mailing lists??? GPS prices? NOS: problem with ALIAS file RTTY ? Send .COM files over e-mail WANT: Computer Aided Dispatch system Where is "ethrax25.zip"? Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 20 Oct 1994 02:45:43 GMT From: kf5mg@metronet.com Subject: ampr.org conventions? In <38391j$pt3@uk-usenet.uk.sun.com>, smckinty@sunicnc.France.Sun.COM (Steve McKinty - SunSoft ICNC Grenoble) writes: >I have several systems tied together on a home ethernet. I want to >assign a domainname covering all of them, within the ampr.org domain. > >Assuming I get the appropriate IP addresses, what is the convention >for this? Would a domain of .ampr.org be normal, with >the systems configured as ..ampr.org etc.? Brian Kantor ( brian@nothing.ucsd.edu I think ) will have the right answer since he runs the ampr.org dns. I've been doing slip.callsign.ampr.org or linux.callsign.ampr.org, etc for local users. No one's complained yet. Check with Brian if your worried. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 - kf5mg@metronet.com - work (looking for) AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 +=======================================================================+ + D.A.M. - Mothers Against Dyslexia + +=======================================================================+ ------------------------------ Date: 20 Oct 1994 08:07:24 GMT From: jcmonier@muguet.saclay.cea.fr (KENWOOD) Subject: Does a TM 732 E/A can work at 9600 bauds ? First, thanks to read this news, Subject say all but I'm added these details : - does someone have make some homebrew about that ? - if the TM 732 can work at 9600 is it directly (original featured) or with a particular mod. - notice I have a 732 E on witch I av perform the E5 mod (see file TM732.mod in /pub/hamradio/mods/kenwood on oak.oakland.edu) Thanks and 73 to all Jean-Christophe MONIER Ingenieur Reseaux / Networks Engineer Athesa - C.E.A. Defense - France E-Mail : jcmonier@muguet.saclay.cea.fr Phone : (33/1) 69.08.56.41 ------------------------------ Date: Wed, 19 Oct 1994 12:44:45 GMT From: rumbalj@govonca.gov.on.ca (John Rumball) Subject: FBB or MSYS mailing lists??? Thank you for reading this posting. I am wondering if there are any FBB or MSYS related mailing lists I can subscribe to, similar to the NOS-BBS list? If you know of such a list, please pass along the details (ie. how to subscribe) to me. Thank you in advance and 73. de John, VA3BUS -- /------\ Ontario JOHN RUMBALL | ()() | Ministry of District Systems Officer rumbalj@gov.on.ca | () | Natural Sudbury, ON Canada va3bus@va3bus.#ne.on.can.noam \------/ Resources (705)722-7823 ext.278 ------------------------------ Date: Thu, 20 Oct 1994 02:50:23 GMT From: kf5mg@metronet.com Subject: GPS prices? I'd like to play with mobile packet and GPS maping. Anyone know where I can find a REALLY cheap GPS device with a built in serial port? Thanks. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 - kf5mg@metronet.com - work (looking for) AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 +=======================================================================+ + D.A.M. - Mothers Against Dyslexia + +=======================================================================+ ------------------------------ Date: Wed, 19 Oct 1994 17:24:00 GMT From: boulaisg@ingenierie.telecom.hydro.qc.ca (Guy Boulais) Subject: NOS: problem with ALIAS file Hi, in my ALIAS file of NOS I made an entry like this: joe fred@abc123.edu When I try to send a mail to "joe", the smtp module tries to send the mail to abc123.edu, but to user "joe" instead of "fred". So the receiver returns me a message telling that user "joe" is unknown. I am using NOS11C-A.EXE Is there any parameter to adjust that? THANKS!!! =============================================== Guy Boulais, VE2GYB e-mail: boulaisg@ingenierie.telecom.hydro.qc.ca e-mail: ve2gyb@ve2ums.ampr.org ------------------------------ Date: Wed, 19 Oct 1994 23:09:04 GMT From: morris@grian.cps.altadena.ca.us (Mike Morris) Subject: RTTY ? FOR SALE, TRADE, OR ???? One Model 28 ASR Teletype, complete. Includes spare Model 28 RO less cabinet i.e. a spare printer mechanism with base. The 28 ASR has a regular friction feed platen. The 28 RO is equipped with a pin feed platen, vertical and horizontal tab kits (was used to print airline tickets). If you really want it I have the Teleticketer (tm) control box - essentially a 300 baud autoanswer modem with answerback and a loop current generator. This unit has been in storage in the back of my garage for the last 5-6 years when the current owner moved from a house into an apartment and asked if he could store it in my garage. I believe it was working at that time. He has since lost interest in it, and told me to get rid of it. Manuals _might_ be available - if any interest is shown, I will put the prospective buyer in touch with the current owner. -- Mike Morris WA6ILQ | All opinions must be my own since nobody pays PO Box 1130 | me enough to be their mouthpiece... Arcadia, CA. 91077 | ICBM: 34.12N, 118.02W | Reply to: morris@grian.cps.altadena.ca.us ------------------------------ Date: 19 Oct 94 19:44:54 GMT From: byon@quicksilver.COM (Byon Garrabrant) Subject: Send .COM files over e-mail Send .COM files over e-mail and packet brian@nothing.ucsd.edu (Brian Kantor) writes: >Or better yet, instead of using UUENCODE, which uses characters that >aren't going to survive some e-mail gateways, use the MIME standard >that does. Why gosh-golly, if you use one of the standards, you might >even find that you don't have to write code to use it, because your >mailer might already understand it. > >But then, being compatable and following standards would take all the >fun out of it, eh? That's why we're AMATEURS, right? >- Brian I believe that unless the recipient of the file/message has a MIME decoder, they will be completly unable to use a MIME file sent to them. There may be many Internet e-mail reader which automatically de-MIME thnigs for you, be I'd bet very few hams on packet have even HEARD of the MIME standard. CODET's purpose is to facilitate the sending a binary file when the recipient has no more software than a terminal program and a text editor. It's a little different than MIME's purpose. I suppose I could have written the program to decode a MIMEed .COM file, but I have seen UUENCODE used more than MIME, I don't know of any packet TNC's that won't pass the characters I used, and what difference does it make to the end user? 73, Byon ---------------------------------------------------------------------- Byon Garrabrant KD6BCH byon@quicksilver.com ------------------------------ Date: Thu, 13 Oct 1994 08:17:22 -0400 From: CSLE87@email.mot.com (Karl Beckman) Subject: WANT: Computer Aided Dispatch system In article <3792jm$sdt@www.interramp.com>, pp000814@interramp.com wrote: > > I would like to know what info turns up here. Several people who work for me > > will be attending a meeting at the Dulles Marriott this week to discuss 911 > > service for PCS and Celluar users. > > > > In article , writes: > > Newsgroups: rec.radio.amateur.digital.misc > > Path: > > interramp.com!psinntp!rutgers!netnews.upenn.edu!msuinfo!caen!spool.mu.edu!sol.c > > tr.columbia.edu!news.msfc.nasa.gov!news.larc.nasa.gov!lerc.nasa.gov!purdue!yuma > > !csn!nowhere!aitsun20!sjames > > From: sjames@tcinc.com (Scott James) > > Subject: WANT: Computer Aided Dispatch system > > Message-ID: > > Sender: news@peacock.tcinc.com (Internet News Administration) > > Nntp-Posting-Host: aitsun20 > > Organization: TeleCommunications, Inc. > > X-Newsreader: TIN [version 1.2 PL2] > > Date: Fri, 7 Oct 1994 21:16:59 GMT > > Lines: 14 > > > > > > I'm looking for a Computer Aided Dispatch (CAD) system > > that links radio modem technology with a GIS display. > > These systems are used by Federal Express (I think) > > and 911 agencies. > > > > If you know of any products or companies that can help > > me find such a system, please email me with the info. > > > > thanks in advance! > > > > scott james > > N0LHX > > To the unnamed pp000814 - As a subscriber and nationwide roamer using cellular mobile service, I have found that every cellular or PCS provider has a different method of interfering when I dial 9-1-1 to report a serious problem on the highways. There is no reason that direct emergency calls to 9-1-1 should be hindered in this way. I found that the wireline cellular carriers in Michigan/Indiana publicize their *-1-1 service, but it just goes into a continuous ring cycle, and of course nobody answers their "O" lines either when you try to report the problem. I believe so strongly in universal 911 access that I am planning to author a formal request for FCC rulemaking in the near future. So, to get directly to your inquiry, what is needed? An FCC requirement that every radio-based voice communications service provider shall directly route any call to 9-1-1 to the local PSAP appropriate for the general area where the call was originated (The same algorithms used to provide automatic transmitter site selection based on signal strength can be used to provide the call routing data). Further, each carrier must provide caller ID information to each PSAP, which is already provided for landline callers. Third, a direct callback input shall be provided so that every PSAP nationwide has the ability to re-dial and re-establish communications to the radio unit without dialing multiple carriers, their various switch access codes, and finally the radio subscriber's assigned number. In short, radio-based comm carriers must have service identical to that provided today by landline telephone providers, and at no charge, so that radio-based subscriber units shall have equal access to 9-1-1 services. Scott - Motorola has provided quite a large number of computer-aided dispatch systems, partnering with various software houses and mainframe suppliers to build very complex interfaces to the "head-end" dispatch center. You should understand that the data protocols used over the air for the roaming data terminals are not the same ones you use fearlessly for direct hardwire connections. I am aware of some the issues at FedEx, but I think you need to talk to professional folks in the radio and computer industries, not radio amateurs. -- Karl Beckman, P.E. < If our English language is so > Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > (Square waves & round corners) < parkway and park on the driveway? > Opinions expressed here do not belong to or represent Motorola Inc. Amateur radio WA8NVW NavyMARS NNN0VBH @ NOGBN.NOASI ------------------------------ Date: 19 Oct 1994 15:24:28 -0700 From: tcj@infoseek.com (Todd Jonz) Subject: Where is "ethrax25.zip"? About a month or so ago there was a thread running in this group about the upcoming availability of device drivers for DOS and/or Windows that would support KISS on Winsock. One helpful gentleman (whose name and call I have unfortunately misplaced) suggested I have a look at: ftp://ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/ethrax25.zip I only just got around to following up on this pointer last evening, and was disappointed to discover that this file has been corrupted. Does anyone know of another site from which this archive can be obtained? Or if the author(s) happen to see this note, perhaps you could repost a clean copy to UCSD? Tnx, KB6JXT, Todd ------------------------------ Date: Thu, 13 Oct 1994 09:00:03 -0400 From: CSLE87@email.mot.com (Karl Beckman) References <1994Oct8.131116.15772@ke4zv.atl.ga.us>, Subject: Re: 56k+ Packet System In article , dts@world.std.com (Daniel T Senie) wrote: > In article <1994Oct8.131116.15772@ke4zv.atl.ga.us>, > Gary Coffman wrote: > >In article dts@world.std.com (Daniel T Senie) writes: > >>In article <36u4fd$56h@push.stack.serpukhov.su>, > >>Victor Voronkov wrote: > >>>Erich Muschinske (erich@enterprise.CHinalake.navy.MIL) wrote: > >>>> Don't be too fast to dismiss this idea. One of the things packet networking > >>>> desperately needs is a cheap high speed data link. This is necessary for > >>>> operating a cellular packet concept. It would only have to work with the > >>>> radio on the other end, so adapting would not be out of the question. If > >>>> the price of a link could come down to about $600, I would be very interested. > >>>IMHO any attempt to get speed more than 9600 on HandHeld or other 'voice' > >>>Radio is problem. Even if we find new modulation. With half-duplex > >> > >>Can I ask a question here? How is it possible to get the necessary S/N ratio > >>and other such to get a V.32bis modem to operate correctly over a Cell Phone? > >>It seems to me that it IS possible for cell phones to provide a clean enough > >>signal to do data over them, so why do hams have so much trouble getting > >>the needed S/N ratio to run at 9600? I must really be dense and missing > >>something. I understand that the example of V.32bis (14.4kbps) over cellphone > >>is point-to-point. So are most amateur 56K links. Why can't we do a high > >>speed link over inexpensive gear and limited bandwidth? It seems to work > >>for cell... > > > >You *are* missing something Dan. It's not SNR that's the problem. While > >it's true that most ham HTs are sorely lacking in adequate SNR over many > >paths for *any* type of modulation, including voice, hence the term handi- > >scratchie, that's *not* the main problem. Cellular phones are like the > >rest of the telephone system in that the phone network handles the addressing > >and routing *out of band*. This means that when the phone rings, the modem > >*knows* the signal is for it, and can initiate a *training* sequence with > >the modem on the other end to equalize and utilize the one transmission > >path then in use. It is an *exclusive* circuit with no other modem signals > >present. > > Most of the high speed packet usage I've seen has been for dedicated point- > to-point links. At least that's the case up here in the northeast. When > that IS the case, the issue of multiple signals goes away (or let's assume > so for the sake of discussion). > > Assume two radios of known manufacture (and same brand and model just to > ensure all is the same). Assume FULL DUPLEX on two frequencies, so that > both ends are ALWAYS keyed and transmitting. This eliminates the call setup > issues. > > Now, I still do not understand how a cell phone can get 14.4kBPS through > a channel where we could not do the same on a dedicated, full duplex > circuit. > > I understand fully the switching mechanisms, dedicated point-to-point nature > of telephones, and the like. What I really want to hear more about is the > actual data over a voice grade telephone circuit part of things. > > > > >The only difference that a cellular modem faces versus wireline modems > >is occasional signal dropouts due to handoffs, and the usual multipath > >concerns. Therefore special modem parameters have to be used such as slow > >disconnect so that the modem won't drop the connection during a brief handoff > >outage, and robust error detection to handle the multipath induced symbol > >errors. We already have all that in packet. > > > >What we *don't* have on packet is out of band routing and addressing, > >and what we *don't* have on packet is *exclusive* use of a frequency > >for a pair of stations. A packet modem has to successfully decode the > > We do have many dedicated frequency links up here. > > >header of *every* packet on the channel to assure that the packet either > >is or is not addressed to it. It *cannot* initiate a training sequence > >every time it hears a packet it can't decode. *That's* why packet modems > >can't use training, and training is the key to high speed data over a > >voice grade circuit. Every telco modem over 2400 baud uses some form > >of training at call setup. In packet, setup must be on a packet by > >packet basis, and that won't work because not all packets on the > >channel are addressed to the same modem. > > So if we were to construct equipment for dedicated links as I described > above, and used training, then we'd be able to get 14.4K or 28.8k data > rates over a 3kHz wide voice passband? (again assuming the dedicated > pair of frequencies, and RF gear of known design). > > > > >With the typical Kenmore, Yahoo, Icky, and Motrash radios used by > >amateurs, no two of them will have the same bandpass characteristics. > >Training is *essential* to compensate for that, and for off channel > >stations. Amateur equipment doesn't have the frequency stability of > >commercial equipment, so it isn't unusual to have one or more radios > >a kilohertz or more off channel. Nor is it unusual to see wide differences > >in deviation from one radio to the next, even among those of the same > >make and model. Any modulation used has to be tolerant of all those > >errors *without* compensation on a packet by packet basis. That's why > >systems as slow as 9600 baud are difficult to setup with more than > >two stations. 2400 baud is about as fast as an uncompensated system > >can work with multiple players. > > > >The limitation is *not* with the modems, it's with the *radios*. > >To successfully use high speed packet, we *must* have radios with > >identical response characteristics, and that means dedicated data > >radios, all optimized for the *same* response. Now it may be possible > >to compensate *all* radios the same way in a system by use of DSP, > >but it's not likely. There are two many variables outside the control > >of the DSP, such as whether the radio is on channel center or not, > >and the differing multipath from one radio path to the next. We > >need identical radios, *and* a modulation that is tolerant of certain > >types of errors. Such systems exist, I keep pointing to the GRAPES > >56kb RF modem as an example, but insistance on using voice grade > >amateur equipment for high speed packet is futile. Amateur packet > >networks are *not* like the telco network, and telco techniques > >won't work. > > I guess I'd always assumed that the GRAPES stuff was used to build backbone > links of a network. From the issues you raise, it appears that this is > a misconception, and that you have set up networks of multi-access > stations over GRAPES modems at 56K. Is this correct? > > -- > --------------------------------------------------------------- > Daniel Senie Internet: dts@world.std.com > Daniel Senie Consulting n1jeb@world.std.com > 508-779-0439 Compuserve: 74176,1347 Gary, please pardon me if I put words in your mouth. I've been tracking the thread for a while and I agree with both your goals and implementation plan. Dan, I think you missed some of the most basic principles that Gary has been trying to make to the amateur community for several years now; 1) You MUST build high-speed networks out of units that perform consistently, predictably, and in a nearly identical fashion. If you don't, you spend more time in establishing and maintaining the circuit than in moving the data. 2) GRAPES is not a just modem, not just a radio, not just a digital (ONLY) modulation method. It IS an integration of all three items into a package with documented, useable (and rather impressive), and repeatable performance parameters. 3) Amateur radio packet networks are BY DEFINITION multipoint networks that must operate reliably while having non-exclusive use of the radio channels. Data links made through telephone networks, conversely, are not shared and are not multi-point. -- Karl Beckman, P.E. < If our English language is so > Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > (Square waves & round corners) < parkway and park on the driveway? > Opinions expressed here do not belong to or represent Motorola Inc. Amateur radio WA8NVW NavyMARS NNN0VBH @ NOGBN.NOASI ------------------------------ End of Ham-Digital Digest V94 #346 ******************************